The present invention generally relates to integrated circuit testing, and more specifically, to functional test and diagnostics for integrated circuits.
When developing integrated circuit systems, resulting devices need to be tested and faults diagnosed. A common diagnostic approach in the industry uses post-test software algorithms that run on fail data collected on a test system. To generate the data, patterns can be applied to a device under test and the responses collected. Failing responses can be fed into design automation software which analyzes the fail data and gives suspected callouts for the defect detected. A set of faults is associated with each design. A typical fault model is the “stuck-at” fault model, which includes both a stuck-at-1 and stuck-at-0 fault. The design is typically a gate-level representation (AND, OR, XOR, etc.), and the faults are applied at the inputs and outputs of each logic block. Based on a complete list of faults, diagnostic software typically produces a callout identifying the most likely faults to explain the faulty response. The goal is to have a precise enough callout so that physical failure analysis can be done on the device under test to identify the physical defect and determine the root cause.
Generally, there are two types of diagnostic techniques: cause-effect analysis techniques and effect-cause analysis techniques. Cause-effect techniques depend on stored symptoms caused by possible faults and use the observed responses to locate the fault. A fault dictionary approach is one such example. Problems with this approach, especially for large chips, can include excessively long simulation run time with prohibitively large memory requirements and ineffective physical and electrical failure analysis due to low diagnostic resolution. In contrast, effect-cause techniques do not depend on pre-stored data but instead process the response obtained from the device under test to determine the possible faults that generate the response. Effect-cause algorithms are less processing resource intensive and are well suited to fault diagnostics. Software diagnostic techniques are typically faster than other methods; however, fault candidates can be wrong or there can be too many candidates with low scores. A fault with a low score is one with a low probability of explaining the failure. This can result from incomplete fail data, un-modeled fault types such as path delay and bridging faults, and faults in areas of logic that are not fully represented in the fault model (such as clock logic). All of these have resulted in a need for better, improved systems and methods.